Subject: HPR Frame Relay and LAN formats

From: "Ray Bird" <[email-masked]>
Date: Thu, 13 Apr 95 15:25:30 EDT

The purpose of this note is to address the concerns (primarily raised by Jim
  Cobban) about HPR's Frame Relay and LAN (e.g., Token Ring, Ethernet) formats.

  Concern 1 is with the HPR Frame Relay format that omits the 802.2 header
  which contains the SAP fields.  Gateway boxes that use SAPs for multiplexing
  traffic from many downstream stations onto a single FR DLCI will not be able
  to do so when both end points are upgraded to HPR.

  We believe that Concern 1 can be solved by using FR bridged packet formats.
  These formats were specifically designed for multiplexing between LANs (e.g.,
  Token Ring and Ethernet) and FR.  (See Multiprotocol Encapsulation Implemen-
  tation Agreements TRF.3.1 for a description of these formats).  FR bridged
  formats encapsulate an entire LAN frame and offer the following advantages
  for gateways.

  o   The number of downstream stations that can be supported is limited to the
      number of mac addresses (2 to the 48th) as opposed to the number of SAPs
      (128).

  o   When gatewaying between a LAN and a Frame Relay DLCI, no mapping is
      required and no tables need be kept because the whole LAN frame is simply
      encapsulated or unencapsulated.

  o   When no mapping is required, gateways are better protected against future
      end point changes.

  o   The HPR SAP (CV80 in HPR CV61) never needs to be parsed or modified.

  Up to now, using the FR bridged format was not a particularly good idea
  because of the lack of support in certain key products, most notably NCP.
  However, many products either already support bridged formats or intend to
  support them in the near future.  For example, NCP, 6611, and 2210 recently
  announced this support.

  This proposed change is relatively simple to implement, is better from a
  technical standpoint (can minimize storage usage and improve performance), is
  more strategic, and more enduring for the long run.

  Concern 2 is on the use of a second SAP for HPR non-ERP traffic used in HPR
  LAN formats.  The purpose of this second SAP is to improve intermediate
  routing performance.  However, it may have the drawback of introducing addi-
  tional complexity into some implementations.

  We agree with concern 2 and also agree that, in retrospect, using UI on the
  APPN SAP (instead of a second SAP) might have been a simpler, less compli-
  cated way to go.  Regrettably, IBM products (and perhaps others) are at a
  point in the development cycle that makes changing at this late date prohib-
  itively expensive.

  In conclusion, we believe concern 1 can be satisified using FR bridged
  formats.  However, although we agree with concern 2, we are not able to
  change the formats at this late date.

  Ray

  P.S. Special thanks to Jim Cobban for his help in clearly defining the prob-
  lems and evaluating various alternative solutions.

---

From: "jim (j.) cobban" <[email-masked]>
Date: Sat, 15 Apr 1995 12:48:00 -0400

>  formats encapsulate an entire LAN frame and offer the following advantages
...
>  more strategic, and more enduring for the long run.

This proposed solution is only suitable if the frame-relay interface device
is actually attached to a LAN.  If it is not then there is no 802.5 header to
encapsulate.  In the case of Northern Telecom we are multiplexing devices
whose original attachment is SDLC or X.25.  It is therefore NOT "simple to
implement".

I believe that it is essential for any solution which is proposed to support
interoperability with the pre-standard IBM implementations.  However I do not
believe that should constrain the RECOMENDED transports for HPR.  I therefore
propose to the SIG the following amendments to the HPR-3 document:

A small editorial note:  Token-Ring should always be hyphenated.

In section 6.2.1 "Frame Relay" the sentences "The second method has been
chosen based upon product performance.  Not invoking 802.2 LLC at all was
better than invoking it and doing UI processing." are omitted from the first
paragraph.  In their place "The choice of method is negotiated in the XID 3
CV 61.  If both end points transmit an XID 3 in which the CV 61 subfield 80
is omitted, or explicitly selects SAP C8, then the second (no LLC)
encapsulation method is used.  Otherwise method 1 is used. <New paragraph>
If it is necessary to multiplex HPR connections over a single virtual
circuit then either the 802.2 LLC header must be included in each frame, or
else the 802.5 bridging encapsulation must be used.  The 802.5 bridging
encapsulation is particularly well suited to frame-relay interface devices
supporting LAN attachment.  Support of the 802.5 bridging encapsulation is
optional but recommended in HPR nodes."  A reference to the new appendix
A.2.4 proposed below is added.

Section 6.2.2 has already been substantially modified to address the concerns
I have raised.  The second and third sentences are a little clumsy and internally
contradictory.  I would suggest "For performance reasons a separate SAP,
different from the SAP currently used to transmit APPN traffic, is normally
used to transmit NLPs with no link level error recovery.  NLPs requiring
link-level error recovery use the same SAP as existing APPN traffic (and the
XID 3 exchange)."  In the fourth sentence replace "processed" by
"identified".  Add to the end of the paragraph "HPR nodes must support 
ERP for NLP transport when required by the adjacent node."

In appendix A.1.10 byte 2 bits 0-1 value 01 is marked "retired".  Northern
Telecom requires this change because we implement an X.25/QLLC to TRN
gateway.  The XID3 generated by the X.25/QLLC native DTE will specify byte 2
bits 0-1 as 00 as specified in section 6.2.4 paragraph 3.  However if our
gateway transmits this XID to a LAN attached HPR node which has specified 01
then "CONDITION 1" applies, and HPR is turned off and an alert is sent.  This
is not functionality which our customers will tolerate.  Therefore this
option must be retired and all LAN nodes must support ERP procedures for
HPR.

Appendix A.1.11 is retitled "LLC (e.g. Token-Ring, Ethernet, Frame Relay)
subfield (X'80')" and the last part of the first sentence is amended to
replace "LAN link ..." with "link using 802.2 LLC procedures (e.g.
Token-Ring, Ethernet and Frame Relay."  In the second sentence LAN is
replaced by LLC.  In the description of byte 2 add at the end "On
frame relay if this subfield is omitted or set to X'C8' by both ends of the
link connection then HPR frames will be carried with no LLC header as shown
in appendix A.2.2."

In appendix A.2.2 a sentence is added at the front of the first paragraph.
"This format is used for non-ERP HPR frames when both stations have chosen
the default SAP."

In appendix A.2.3 a sentence is added at the front of the first paragraph.
"This format is used for ERP HPR frames and for non-ERP HPR frames when
either station has chosen a SAP other than x'C8' in CV 61 subfield 80."
In bytes 8 and 9 the text from the colon onwards is removed.

A new appendix A.2.4 is added, forcing the renumbering of all subsequent
sections under A.2.  It is titled "Frame Relay Format for 802.5 Bridge
Multiplexing".  The contents of this appendix are extracted from the
Frame-Relay Forum Multiprotocol Encapsulation over Frame Relay document (= RFC
1490).  The first paragraph starts "This format is used when it is required
to encapsulate multiple logical link connections, which may be either HPR or
ISR."